This invention relates generally to accessing system management information for a processor-based system and, more particularly, to providing seamless access to system management information in a foreground operating system.
In modern computer systems, system management activities such as those associated with temperature, voltage, and front panel button monitoring may be performed by routines that operate transparently to the operating system. One example of such a mode is termed System Management Mode (SMM) and may be entered through activation of an external system interrupt pin which generates a System Management Interrupt (SMI). Similarly, an Inter-Processor Interrupt (IPI) message may be delivered or generated by the integrated Advanced Programmable Interrupt Controller (APIC). In response to an SMI, the SMM may handle the event with system management functions such as reduced power consumption, debugging, or hardware emulation. Another example is an Itanium processor that may be accessed through a pin that provides a Platform Management Interrupt (PMI) signal, and an interrupt message that may be delivered through the Streamline Advanced Programmable Interrupt Controller (SAPIC).
System management functions may be performed independently of the operating system. Before handling a system management event, the processor's entire operating state or internal state may be saved to a separate, protected and dedicated memory space which may be referred to as SMM Random Access Memory (RAM). Then, the computer system's firmware, instead of application programs or the operating system's software, may control product-specific hardware features.
A system management handler may determine what system management event occurred and take appropriate action. For example, if the event was a reading from a temperature sensor exceeding a specified value, the appropriate action may be to suspend operation of one or more non-essential devices or components. The handler also may modify one or more hardware registers and/or system memory locations to indicate the occurrence of the event. The handler may commence execution in real mode, and may transition into protected mode, during which the processor executes out of a separate address space. In other processor-based systems, including the Itanium architecture, the processor may execute in physical mode.
In the past, to obtain information about the occurrence of system management events, applications could poll the operating system. On expiration of an application specific timer, the system management application could initiate a query to examine the hardware registers and/or system memory locations that the handler modified. If the handler indicated a change relevant to the initiating application, this information was returned to the querying application and processing continued. If the handler did not indicate a change relevant to the initiating application, normal processing continues. However, this approach had several disadvantages including wasted processor time and a lack of synchronization between the event and the action.
It has been cumbersome and difficult to access or view system management information in live or real time during the pre-boot as well as in the runtime environment. For example, system management information obtained during pre-boot may not be conveyed to the operating system. For example, in the past, drivers in SMM have used back-channel communications, such as out-of-band serial ports or network, as a console. Conveying system management information to the operating system involved a kernel-mode driver to driver/firmware call. Or, SMM drivers logged information to persistent store, such as flash memory, that could be accessed on a subsequent restart in protected mode.
There is a need to provide live system management data, which can include alerting, status, etc., to the user during the pre-boot and in a runtime environment. There is a need for system management data obtained during pre-boot to be accessed during runtime of an operating system. There is a need for system management data to be readily accessible by a user through the operating system, for example to determine what system management event occurred, such as platform errors, thermal events, and other platform exceptions, and/or what actions the responding handler has taken.